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Abstnct-' 

The General Purp>we Automation Controller is a multi-processor 
architecture for automation programming. A methodology has been 
d e v el op e d whose aim is to simplify the task of programming distrib- 
uted real-time systems for users in research or manufacturing. Pro- j 
grams are built by configuring function blocks (low-level 
computations) into processes using dau flow principles. These 
p roc e s ses arc activated through the verb mec h a n i sm . Verbs are di- 
vided into two classes: those which support devices, such as robot 
joint servos, and those which perform actions on devices, such as 
motion control. This programming methodology was developed in 
order to achieve the following goals: 1) Specifications for real-time 
pr o g rams which are to a high degree independent of hardware con- 
siderations such as processor, bus. and interconnect technology. 2) 

A "component" approach to software, so that software required to 
support new devices and technologies can be integrated by recon- ! 
figuring existing building blocks. 3) Resistance to error and ease of 
debugging. 4) A powerful command language interface. 

Introduction 

Recent system designs aimed at solving problems in automation 
control have made significant use of multiprocessing [1-7). Typi- 
cally these systems incorporate a variable number of processors 
performing computations in parallel and exchanging data by means 
of some interconnect technology. These technologies are usually 
compatible either with/a shared memory model [6] of data exchange 
or with a message-passing model [5.7]; occasionally, systems may 
exhibit features of both models. If all processors execute the same 
program, the system is said to be S1MD ISingle Instruction. Multiple 
Data), however the greatest flexibility is achieved with a M2MD 
( Multiple Instruction. Multiple Data ) system. 

Multi- processor systems not only offer the prospect of increased 
computing power' to meet the ever-increasing requirements of real- 
time control, they carry the potential for a high degree of 
configurability. One of the obstacles to rapid progress in robotics 
research and the deployment of programmable automation in scien- 
tific and manufacturing applications is the lack of configurability in- 
herent in roost currently available systems. The need for 
configurability arises from the need to integrate new devices, employ 
new strategics, or add processing power incrementally without 
making major changes to the system; for software this implies a need 
for "fast prototyping", the ability to construct software that can 
rapidfy adjust to changing requirements [8.9|. However, multi- 
processor systems cannot be used to tackle this problem un l es s an- 
other problem is simultaneously addressed: the lack of tools and 
methodologies to simplify the task of programming such systems. 

Who I a m Progr am mi ng Met hodolog y ? 

A true programming methodology is not simply a collection of toots 
or techniques, rather it provides a set of concepts, usually formally 
or aemi-formally defined, which serve as a basis for problem de- 
composition and program design. [10) This is a fairly definitive re- 


quirement which is not covered by vague terms indicative of a 
general approach, such as "top-down design" or "object-oriented 
programming". 

A methodology has a number of advantages over a "toolbox", of 
which the following are representative: 

o The evolution of tools and techniques does not always promote 

mmr of use, and of themselves tools do not help to guarantee 
good program design. [ 1 1 ] 

• A methodology provides a powerful la n guag e for describing the 
function of a program or specifying its design. 

a A methodology can provide a framework for reasoning about 
the correctness of a program. 

a Programs developed according to a methodology are often 
easier to maintain. 

This paper describes such a programming methodology developed in 
conjunction with a General-Purpose Automation Controller 
(GPAO project at IBM [8.9). The ultimate aim of this methodology 
is to simplify the mi of programming real-time, distributed systems 
for manufacturing engineers, control specialists, and other system 
users whose primary area of expertise is not computer science. 

Currently, most distributed programs are written either in a concur- 
rent lan guag e for which a distributed environment has been bait (e. 
g., Ada [12,13]), a conventional sequential language with enhance- 
ments for distributed programming [4.7). or a special-purpose lan- 
guage 1 14). None of these approaches is particularly adept at 
dealing with highly reconfigure bie systems. To change the behavior 
of a system one must make changes to the program’s source lan- 
guage. re-compile, re-link, re-download, etc. The usual approach is 
to provide primitives [13.16] (either as part of the la n guag e syntax 
or as system calls) for communication, synchronization, mutual ex- 
clusion. and even control over the granularity of concurrency. Ap- 
plication programming in such a system involves not only getting the 
sequential algorithms right but also managing the interaction be- 
tween concurrent modules and using the primitives correctly. Many 
of the programs developed using these approaches are dependent for 
their performance, if not for their correctness, on a particular model 
of data exchange. Finally, there is no true methodology associated 
with these approaches, although useful tools such as debuggers, 
simulators, and syntax-directed editors are often provided. 

Bask Concepts 

The GPAC programming methodology depends upon a set of basic 
cooccpts relating to both hardware and software. 

Umdumo 

The fundamental hardware concept in GPAC is that of a tealtime 
processor. Each real-time processor is a distinct entity which can 
perform one or more computational tasks. Each real-time processor 
has its own instruction stream, hence the GPAC model is MfMD. 
A set of real-time processors sharing a common co mmun icatioas bos 
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or n etwork is a real-time system (RTS). Progra ms are developed on 
a programming system (PS) and are then downloaded into (he real- 
time process o rs. Associated with each real-time processor are one 
or more interrupt sources. An interrupt source, in the abstract, is 
simply a request to a real-time processor to perform some work. 
Interrupt sources have priorities: work performed in connection with 
one interrupt source can be preempted by an interrupt source with 
a higher priority. Interrupt sources can be generated by other real- 
time processors or by devices connected to the real-time system It 
is important to remember that the notions of interrupt source and 
priority are fundamentally abstract, and may be realized in the actual 
system in a number of ways. One last hardware concept is the 
physical Jerice. A physical device is a gateway by which data can 
be passed to and from external hardware and is accessible by a par- 
ticular real-time processor. Sensors, actuators, pendant interfaces - 
to name but a few • are examples of physical devices. 

In GPAC. as in other systems ( 16|. implementation of the PS is de- 
coupled t om that of the RTS. so that the architecture of the PS can 
be quite different from that of the RTS. as it should be since the re- 
c,u»rcmcr.ts are different. 

Function Blocks 

The fundamental software concept in GPAC is that of a function 
block (9). A function block is a basic computational unit assigned 
to one or more real-time processors; it communicates through input 
ports and output pvrts. In addition, a function block may communi- 
cate with physical devices, and may report conditions. or events which 
require exceptional action by the system. Finally, a function block 
may have some formal parameters, which arc for its internal use only 
and normally not visible from outside. These Five components 
comprise the interface to the function block. 

A function block can be viewed externally as a "black box" which 
takes inputs, performs some computation, and produces outputs 
(and in some cases, reports conditions). We denote the inputs, out- 
puts. devices, conditions, and parameters of a function block F by 
! f .Of. D f . . and F, respectively. 

The most basic form of function block is called an application sub- 
routine. In the current system, this is coded in the C language (17] 
and corresponds to a C function. A set of macros is used to specify 
the interface; this hides any implementation details from the pro- 
grammer. 

An application subroutine is written in sequential code, and of itself 
contains no notion of concurrency. If certain coding conventions 
are followed, the application subroutine is also re-entrant, and mul- 
tiple instances of it may be active either on the same real-time 
processor or on different real-time processors. A function block in- 
stance is obtained by binding the ports to specific data objects, sup- 
plying actual references for the physical devices, and values for the 
conditions and formal parameters. Other preconditions for the cre- 
ation of a function block instance are its assignment to a particular 
real-time processor and interrupt source, and determination of the 
means by which it is scheduled. 

Ikm Flow Gnpts 

More complex function blocks can be built up from simpler ones 
such as application subroutines. These complex function blocks are 
called data flow graphs. 

A data flow graph G consists of : 

• A set F of function blocks. 

• A set / 0 of input ports, a set of output ports, and a set of 
local cells. 


• A mapping p:/ 6 UO t Ul<-* 2**c where fata 6 are (he data 
nodes of G : 

Wg 

All the data nodes must be mapped to by p. L e.. for a my d e fau<, 
(here existtp such that d c pip). 

A data flow graph is composed of communicating function blocks, 
but externally it is indistinguishable from an appficatioa subroutine. 
Data flow graphs are useful for expressing distributed execution of 
an algorithm. For example, a servo algorithm usually involves read- 
ing some value from a sensor, performing some computation, and 
writing another value to an actuator. In a distributed system, how- 
ever. there is no guarantee that the sensor and actuator will both be 
accessible from the same real-time processor. Thus, in general, this 
algorithm cannot be executed by a single application subroutine, an 
instance of which is constrained to run on a single processor. 

Data flow graphs are also useful for pasting together application 
subroutines of general utility. Perhaps we wish to add some digital 
filtering to the input in our servo example. This can be done most 
conveniently by building a data flow graph, provided some digital 
filtering module has already been installed as pan of the software 
component data base. 

Ports of Function Nocks 

Each input and output port of a function block has a type and a 
mode. The type is simply a C type declaration. Ports can be bound 
to data objects only if those objects have a compatible type. The 
mode of a function block port describes the relationship between the 
modification, or updating of the object to which the port is bound, 
and the frequency with which the function bloc* is executed. 

There are three port modes: 

• synchronous - The object bound to the port is updated on every 
invocation. 

• ratio - The object bound to the port is updated at a specified 
sub-frequency of the frequency of invocation. 

• asynchronous - There is no fixed relationship between the up- 
dating of the object to which the port is bound and the fre- 
quency of invocation. 

Thus, if a function block has a synchronous input port, an instance 
of it can be scheduled for execution only when a new value of the 
object bound to the port is made available by another fund ion block 
instance which writes the object through an output port. 

If a function block has no synchronous inputs, then it can be sched- 
uled by assignment of an execution interval or a trigger. The exe- 
cution interval specifies a frequency at which the function block 
must be executed; a trigger associates execution of a function Nock 
directly to occurrence of an interrupt source. 

Another rule enforced by the GPAC system is that values produced 
by a function block are not made available to other function blocks 
until the former has completed its current invocation. This **ves an 
atomic flavor to function blocks and helps to insure that the world 
will always be seen in a consistent state. 2 

Adva nta ges of the Function Block Concept 

Specification of real-time computations using the function Nock 
concept has the following advantages: 

• Real-time requirements are separated from the executable 
code. This means that instances of the same code can be in- 
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• Function Mocks have do k no wl edg e, and coaoBqotody do de- 
pendence. on the port t c nlaf data exchange model Although 
the cunent GPAC architect ore it based on shared Me m ory, the 
system coaid be im pl e mented using message pitsing without 
affecting the design of ap plications written for it. 

• By standanfizang the interface to fuactioa blocks sad hiding the 
an p ie me matron detaSs, we hope to encourage programmers to 
design routines that win be easily reusable. One problem which 
has emerged historical l y in the "component’’ approach to soft- 
ware design is that, in the absence of a methodology, the suc- 
cess of the approach is dependent upon the good judgment and 
foresignt of programmers. 

• Consistency in data typing is automatically checked. Primitives 
for synchronization and mutual exclusion are u nn e ce ssary, 
hence their misuse is impossible. The result is a system that is 
more robust and easier to debug and maintain. 

Processes in GPAC 

Work done by a real-time system is normally divided into processes. 
In GPAC. these processes are merely sets of comnvmacating func- 
tion block instances. Function block instances are installed before 
they can be executed: this consists of setting op the port bindings 
and attaching the function block instance to the proper processor 
and interrupt source. Consistent use of data objects bound to ports 
and of function block scheduling is checked during installation. 

A typical GPAC process will consist of three phases: 

• Installation of function block instances to be used. 

• Execution (cither once, or repetitively) of one or more function 
block instances. 

• Waiting for termination of aD the function block instances, or 
for a function block instance to report a condition that results 
in process termination. 

As an example, consider a process to implement coordinated motion 
of several robot joints. This process requires two function blocks: 
one which computes the coefficients of a trajectory (L e.. desired 
joint position as a function of time) based on the c um a t positions, 
target positions, speed limits, etc., and another which generates 
intermediate points along the trajectory and outputs these com- 
manded positions to the joint servo modules. (The servo modules 
themselves are considered part of a different process, as we shall see 
shortly.) The First function block, called the trajectory planner, is 
executed once, the second, called the setpoint genera to r , is executed 
repetitively at some time interval (e. g.. 20 msec). The whole proc- 
ess terminates when the current (sensed) position of the joints be- 
comes close enough to (he target position. 

Commmd Lists 

We now describe the above process behavior using GPAC termi- 
nology 

1. Install the trajectory planner and the setpoint generator. 

2. Execute the trajectory planner once. 

3. Activate the setpoint generator for repetitive execution. 

4. Wait uMjI the setpoint generator reports that the motion has 
completed (L e.. the sensed position is dose enough), or that 
some ocher condition (unexpected force sensed, time limit ex- 
ceeded. etc.) has occurred. 

This description of a process is called a command list in GPAC. The 
elements of a command list are caDed function block commands and 
take function Nock instances as arguments. A process consists of a 
command fist and a set of termination conditions. 


In the cane of robot motion, how e ve r , termination c on tfi ti on s are 
often simply signals that the system should proceed with the m o ti o n 
using a somewhat different plan. Tin is pnrtirNar ty true In 
compliant motion and specialized combinations of motions sack as 
ce nter ing grasp [8]. la these cases the termin a ti o n of a proces s re- 
sults in a transition to another process. 

Ml 

We now have developed the necessary con cep t s to define a an* in 
GPAC. A verb V comists of: 

• A set f r of function blocks. 

• A set pr of parameters. 

n A set o, of output values. 

• A subset iastf of py and a mapping x : hmt r -* 2*"*r where 
4to, is the set of aO data nodes m V . L e.. the union of afl in- 
puts. outputs, and physical devices in the function blocks of V: 

4mi* y - (J l f UO f UD r 

r. f % . 

• A mapping 4> :pr — Inst* -» where va li r is the set of all 
ralues accessible within V. which indudes all the ports as wed 
as the conditions and parameters: 

•ah, - U VUOfUCfU^ 

r,fy 

• A mapping u : <v — nfa r . 

• A sel e, of command lists, of which one is distinguished as ini- 
tial 

• A set I, of termination conditions. 

• A mapping t : Dasw, — c, where smt r is the tranHwm of V, 
a subset of r, * 

• A mapping v : term, — 1‘v . where tens, is the set of srrmi- 
nanons of V : 

teem |- - I r : 3r < <y a (cj)l tn m «y t 

lust, are the instantiation parameters at the verb, and x * the 
instantiation mapping. These elements describe the coirnmnartion 
of data to and from the instantiated function blocks of the verb. The 
verb parameters not in imt, are cafied input p aramet er s and the 
mapping + is the inp* mapping. These dements des c ri b e hoar i ni ti a l 
values are set up to be accessed by the instantiated function Nocks 
of the verb. The mapping is the output value mapping which de- 
fines a set of values that may be returned from the verb. 

Instantiation parameters are either data objects which can be bound 
to function Nock pom or references to physical devices. Input pa- 
rameters are simply values which can be stored in the objects bound 
to ports or in conditions or parameters of a function block. As in the 
case with the mapping p for data flow graphs, every member of 
data, must be a member of some set m the range of x; that a. every 
data node is mapped to by some instantiation parameter. 

if t<c, j) — c : then if condition t occurs while the process described 
by r, is executing, that process is aborted and the process described 
by c. commences. If no transition is specified for a given tr munition 
condition and process, then receipt of that condition within the 
process causes termination of the entire verb. 

The mapping v de scri bes the termination actions of a verb Each 
termination of a verb can return a subset of the output vafaes de- 
fined for the verb. 
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The instantiation parameters of a verb provide bindings for the ports 
of Hie constituent function blocks of the veib. Thus, a p p l v c e e ion of 
para m eters to a verb yields function block imtaners for each of the 
constituent function blocks, and the coOeetioo of these defines a rrrb 
instance. A verb instance in GPAC dosdy resembles the concept 
of a an* in more traditional systems. Verb instances can be started, 
haded, suspended, and resumed. 

The distinction b e tw ee n verb and verb instance can easily be ap- 
preciated by analogy with an operating system utility rr tiling as a 
binary image on secondary storage. When the utility is invoked by 
a user, its inputs and outputs are bound to actual files and devices 
and a task, or main memory image, is created. Furthermore, multiple 
instances of the same utility can sometimes be active in the system 
simultaneously. The same is true for multipie instances of a verb in 
GPAC. 

Verb instance commands arc passed from the Programming System 
to the Real-Time System, where they are esecuted by the n p mi wiy 
software. In every RTS. there is one real-tune processor which is 
distinguished as the supervisor. The supervisory software is down- 
loaded (possibly along with applications code) into this processor, 
and it maintains communication with the PS while the RTS is run- 
ning its applications. While the PS sends verb i n sta nc e commands 
to the RTS. the RTS sends notification of verb instance termination 
to the PS. 

AH real-time processors, whether or not they are supervisors, con- 
tain a real-tune kernel which is primarily responsible for handling 
interrupts, context switching, and dispatching of application sub- 
routines. The supervisor handles al activity related to: 

a Installation, activation, and deactivation of function block in- 
stances. 

• Transitions between command lists, 

a Termination of verb instances. 

State Vector Variables and Logical Devices 

We have previously referred to the representation of data within 
GPAC without providing any details- Data which must be commu- 
nicated between function blocks is represented by the concept of a 
state vector variable ISW'I. It is perhaps easiest to think of an SW 
as shared memory, but it need not be implemented that way. A state 
vector variable contains a buffer for the current value, and op- 
tionally a buffer for a set of pvrvm ms valors, in case a history needs 
to be maintained. State vector variables arc bound to function Mock 
ports in order to effect communication between function block in- 
stances. Associated with each SW is a type, and it can only be 
bound to ports of the same type. 

Although a state vector variable is essentially an independent con- 
cept. the primary method of creaung and using the SW in GPAC 
is through the more powerful concepts of a logical device and a log- 
ical device type. A logical device type coarisls of: 

• An optional verb. 

• A specification for a set of SWs. 

• A specification for a set of parameters. 

A logical device can be considered an instance of a logical device 
type and consists of: 

• An optional verb instance, 

n A set of SWs. 

• A set of parameters. 

A robot joint is an excellent example of a logical device type. With 
each joint in the system we normaty warn to maintain the following 
data: 


• The current sensed posi ti on of the joint. 

• The current commanded position of the joint. 

• The goal, or target position. 

Tim data win be stored m SWs. since it wig be updated by function 
Mock mnanccs in real time. We may also associate certain parame- 
ters with a robot joint: 

• The maximum speed at which the joint can be moved. 

n The maihmim farce or acceleration to which it may be sub- 
jected, etc. 

These values do not normally vary in real time and hence do not 
need to be stored in state vector variables. 

Logical Devices as Verb Parameters 

A verb any be a pp li ed to ooe or more logical devices: akeraatively. 
we might say that logical devices can appear as the objects al verbs. 
In this case, the state vector variables and parameters which com- 
prise the logical device will be entered into the parameter Bn from 
which the verb instance sriB be constructed. Thus they can be bound 
to the pocu and parameters of function blocks which w> perform 
the computations associated with the verb. 

A robot joint is controlled by some real-time process (servo) This 
is implemented as a verb in GPAC. The definition of a logical device 
type foe the robot joint contains specifications for the irrmmgverb. 
the SWs. and the parameters. Then, when an instance of a joint is 
created, the actual verb instance. SWs. and parameters are created 
for that device. 

Before a device may be used as the object of some action (c. %.. be- 
fore a print may be moved! it must be enabled. Enabling a device is 
equivalent to starting the verb instance which controls the device. 

Verb Com position 

Verbs may be composed, or combined to form new verbs. A com- 
position of verbs can be formally defined by taking unions of all the 
verb components; the verbs may then be sequenced by umpiring an 
augmented transition mapping, la Ibis way verbs with a highly spe- 
cialized semantics can be assembled out of simpler, more general 
ones. (A verb with only one command fat is called simple.) An ex- 
ample of this is "centering grasp” found m 1*1 and [9|. 

Levels of Control 

The GPAC methodology supports programming toe various levels 
of control. |9| 

• Closed-loop control is achieved through low-level real-tune 
computations such as application subroutines and tea flow 
graphs. 

• Concurrency control is concerned with specification of compu- 
tations executing in parallel and is achieved through coafigura- 
Uou of command lists and simple verbs. 

u Segnen ne> control deals with plans and strategies foe executing 

complex motions or tasks and is achieved primarily by verb 
composition. 

ruignming foe different levels of control involves different issues 
and areas of expertise, this is reflected in the methodology. 

User Interface 
AML IX 

The GPAC user interface is a program ru n n in g on the Programming 
System. Commands entered by a user are converted from a high- 
level form into actual messages to be sent to the Real-Tnre System. 
Also, configuration of system hardware and software is done via the 
user interface. 
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Because of the many abstractions and generic entities in the CPAC 
system, the high-level language AML/X was used to implement the 
user interface. AML/X is « language de ig ned at IBM for auto- 
mation programming and other applications [18) . It has a number 
of interesting features, among which the three most relevant Id 
CPAC are: 

• Data abstraction capability. An abstract data type is called a 
ciasr. instances of classes consist of tfutmer variables which can 
be manipulated using methods, a specialized type of subroutine 
call The methods define the interface to the data type, except 
that some instance variables can be declared exposed, which 
makes them visible externally and hence part of the interface. 

• Operator overloading. Operators can be defined on dass in- 
stances. using a syntax similar to the method syntax. In par- 
ticular. the act of applying parameters to an object is regarded 
as an operator in AML/X: this allows GPAC verb invocation 
to have the same syntactic form as subroutine invocation. 

• Exception handling. AML/X has a rich set of constructs for 
raising and handling exceptional conditions ( 1 8). 

AML X can be easily interfaced to lower-level languages like C and 
FORTRAN. In fact, the communication between the PS and RTS 
in GPAC is handled by a C subroutine package which is called from 
AML/ X. 

Configuration ami Frer m tiom Phases 

The GPAC user interface consists of two parts: a comfigunuto * i phase 
and an execution phase. 

In the configuration phase the hardware layout is described, in terms 
of real-time processors available, interrupt sources, and physical de- 
vices attached to the processors. Next, previously compiled and 
linked object code modules are downloaded into the real-time 
processors ( For the most part, these modules are simply libraries 
of application subroutines linked with a real-time kernel. ) Then ge- 
neric objects such as function blocks, verbs, and logical device types 
are defined. Finally, some instances of logical devices may be cre- 
ated and enabled. 

The execution phase consists primarily of invocation of verbs. Verb* 
are applied to devices to create verb instances, and commands con- 
cerning these verb instances are then passed to the real-time system. 

Configuration and execution phases can be interleaved to a certam 
extent. New function blocks, verbs, and logical devices may be de- 
fined at any time, and existing verbs may be redefined. This can be 
done »hiie real-tune applications are running (as long as no in- 
stances of the affected verbs are still executing). The goal is to 
pnndc a highly interactive programming environment in which 
real-time system behavior can be modified in a very flexible and 
dynamic way This meets the needs of both robotics researchers, 
who wish to experiment with alternative control strategies and new 
sensor and actuator technologies, and manufacturing engineers, who 
are responsible for reconfiguring work cells to meet changing wort 
requirements. 

Modes of Verb Imeocmim 

The full life cycle of a verb instance can be described as follows: 

• A verb ts invoked by applying it to a parameter kst. These pa- 
rameters are processed by the PS and the informal ion needed 
to create an instance of the verb is sent to the RTS. 

• The RTS allocates and fiQs m the necessary data structures, and 
reports completion of this procedure to the PS. 

• The PS sends a command to start the verb instance 

• The uutiai command lest of the verb is executed on the RTS. 
The verb instance cootmues to execute until some condition 


farces it to terminate or until a suspend or hair mange is re- 
ceived from (he PS. 

• When the verb instance terminates, the RTS sends notification 
to the PS. Depending on the reanoo for the trrmnmrinn. an 
exception c ly be raised oo the PS. 

• Finally, the PS sends a command lo delete the verb instance. 
The RTS complies, cleaning up and d e a lloca t in g al data struc- 
tures. 

In the simplest mode of invocation, tins entire scenario iscarried out 
synchrooousty. The user simply applies a list of arguments to a ob- 
ject of the verb dass, e. 

mo ve( joint ,goal .speed); 

The above operation will not complete until the correspond in g verb 
instance terminates in the RTS and is deleted. 

A more efficient, although more verboue, mode of invocation is 
provided by introducing an asynchronous phase: 

vi: BIND move. asyncM joint .goal .speed); 

/* other work can be done here */ 
vi .wai t( ) ; 

asyach is a verb method that results in creating and starting a verb 
instance, and returning a verb instance object without wasting for 
termination. At some later point in time, the verb instance can be 
waited for. and it is deleted after its termination. 

Finally, a verb instance can be created and then mukxptf invoked 
with new input parameters each time: 

vi: BIND move .new_ instance ( joint); 
vi .start (goal .speed) ; 

/* do something else V 

vi ,wai t( ) ; 

vi . star t ( another _goa I .another speed) ; 

/* do something else V 
vi .wai t ( ) ; 
vi ,delete( ) ; 

Currant Status and Future Work 

The GPAC methodology has been implemented in conjunction with 
several different hard * are architectures. The relative ease with 
which applications can be ported back and forth b e tw een these ar- 
chitectures is ooe encouraging result of our work. We have also 
observed that real-time computations are easy lo program, require a 
minimal amount of debugging, and have predictable behavior once 
Je rugged. Ftnafiy. the system can be easily reconfigured, aew de- 
vices and processors can be added wufcout laborious chang e s and 
recompilations. 

We have used a certain amount of formalism to doerbe the con- 
cepts underlying the methodology rather than relying 00 configura- 
tion examples in AML/ X. We chose to do this became it is the 
formalism foot the current configuration syntax) winch is really 
critical to understanding the methodology, because we did not wish 
to require detailed knowledge of AML/X of the reader, and because 
the syntax itself is subject to considerable change and enhancement 
as we gam experience with the system. 

In the future, mure sophisticated applications will be attempted using 
this methodology. We wil then be able to judge the efficacy of the 
methodology for practical problems in automation. Graphical tools 
will be added to simplify verb and data flow graph configuration. 
Knowledge-based enhancements and aaturaHanguagr-lifcc inter- 
faces arc aHo contemplated. 
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